home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 10635 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.8 KB  |  74 lines
  1. Newsgroups: comp.arch.arithmetic,comp.lang.c,comp.lang.c++
  2. Path: cwi.nl!dik
  3. From: dik@cwi.nl (Dik T. Winter)
  4. Subject: Re: Access carry flag from C
  5. Message-ID: <Dnz4AA.Jv2@cwi.nl>
  6. Sender: news@cwi.nl (The Daily Dross)
  7. Nntp-Posting-Host: chrysant.cwi.nl
  8. Organization: CWI, Amsterdam
  9. References: <4hhbt8$1d3o@b.stat.purdue.edu> <Dnssxu.JGy@cwi.nl> <313D385C.4651@xnet.otm.fi>
  10. Date: Sat, 9 Mar 1996 00:06:10 GMT
  11.  
  12. In article <313D385C.4651@xnet.otm.fi> Jouko Holopainen <jouko.holopainen@xnet.otm.fi> writes:
  13.  > >  > >   if (x + yl < yl) ++yh; /* test for overflow on next line */
  14.  > >  > >   yl += x;
  15. ...
  16.  > Just for fun, let's compare carry and non-carry assembly 
  17.  > (kinda x86):
  18.  > Without carry:
  19. ...
  20.  > With carry:
  21. ...
  22.  > See any difference?
  23.  
  24. Yes, I see a difference.  So what?
  25.  > 
  26.  > Optimizing an addition away might in fact slow down. It just 
  27.  > depends whether tmp and/or x,yl,yh are register variables.
  28.  
  29. If it slows down it is not an optimization and so an optimizer should not
  30. do it.
  31. ...
  32.  > > But the code above also works on machines without carry bit.
  33.  > 
  34.  > Yes. In fact, the latter cannot be produced with C
  35.  > (or any other high level language, for that matter). 
  36.  > Which was the original point.
  37.  
  38. No?  But if a compiler sees the ideom:
  39.     unsigned long x, yl, yh;
  40.     ...
  41.     if(x + yl < yl) yh++;  yl += x;
  42. he is entitled to create code that uses the carry bit from the addition
  43. in the subsequent increment.  Although I do not know any real life compiler
  44. that does this I know there exists a super optimizer that does such
  45. transformations.  You should not expect that code as you present it to
  46. a compiler will be compiled in a literal fashion.  I know of some
  47. compilers where it would hard to deduct the original code from the
  48. assembly generated (*).
  49.  
  50. On the other hand, suppose there is a function carry that returns the
  51. carry bit of the operation embedded in the parameter list (yes, it is
  52. a bit difficult to formalize) so that you can write:
  53.     yh += carry(yl += x);
  54. or something like that.  It is clear that on a machine that has no
  55. carry bits this should be translated to the ideom above, as it can
  56. not be translated directly.
  57. --
  58. (*) Suppose you see the following assembler equivalent in pseudo C:
  59.     vector register float v[128]; int i; float f;
  60.     v[0:128] = 1.0;  /* Meaning: set 128 elements of v from element 0 to 1 */
  61.     for(i = 0; i < 8192; i+= 128) v[0:128] *= 2.0;
  62.     v[0:64] *= v[64:64];
  63.     v[0:32] *= v[32:32];
  64.     v[0:16] *= v[16:16];
  65.     v[0:16] *= v[1:16];
  66.     f = v[0] * v[2] * v[4] * v[6] * v[8] * v[10] * v[12] * v[14];
  67. would you expect that the original (real C) code was:
  68.     f = 1.0;
  69.     for(i = 0; i < 8192; i++) f *= 2.0;
  70. ?  (Why so difficult?  It is faster on that machine.)
  71. -- 
  72. dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924098
  73. home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik/
  74.